[If you are reading this and didn't get it via bugtraq, you are on a scatter-shot list assembled from various sources including old FTP transfer records and my own personal knowledge of who had been playing with deslogin. This mailing is necessarily overbroad and will undoubtedly generate several errors and misdirected messages, so if you have no idea what I'm talking about herein then simply ignore this.] IMPORTANT IMPORTANT IMPORTANT --------- --------- --------- While recently looking through "deslogin" in search of something completely unrelated, it suddenly hit me that I had MAJORLY fucked up in my fixkit for it. This is an excerpt from the tentative doc for the next kit, if I even bother doing one. If you are using my "dl133" fixkit, STOP USING IT IMMEDIATELY and at the very least switch back to the original. It might make more sense for you to switch to something stronger like SSH anyway. Version 1.2 of this so-called fixkit changed the challenge/response protcol and in so doing, introduced a weakness that effectively sends the session key over the network. The ORIGINAL protocol is as follows, where (E) is an encryption using the user's secret key and (D) is a decryption: time & PID --> (E) --> challenge "plaintext", or P P --> (E) --> challenge, which is sent to the incoming client challenge --> (E) --> session key The client receives the challenge, and does challenge --> (D) --> P, which is the response sent back to the daemon challenge --> (E) --> session key The daemon checks that its notion of P matches the client's notion of P to authenticate the connection, and both sides enter encrypted mode using the mutual session key. I naively thought that sending the challenge and then the direct decryption of the challenge was a bad idea, and changed the protocol to do time & PID --> (E) --> plaintext, or P1 P1 --> (E) --> challenge, sent to the client P1 --> end-bytes-flip --> permuted plaintext, or P2 client response --> (D) --> compared against P2 P2 --> (E) --> session key The client would then do challenge --> (D) --> P1 P1 --> end-bytes-flip --> P2 P2 --> (E) --> response, sent back to the daemon P2 --> (E) --> session key Note that the client just sent the *raw session key* back as the response!!! While the original protocol still sends ciphertext and then its plaintext across the wire, it is obviously much stronger than my scheme. At the time I hatched the replacement scheme I did not look deep enough into the guts to realize that the sessionKey() routine was doing one more (E) of the challenge to derive "keybits" for the session key [the last step in both sides of the protocol]. I can only hope that the "dl133" fixkit did NOT get wide distribution, and that anyone currently using it reads this and promptly builds a new version using the original auth.c from Dave's distribution. It is very easy to screw up when dealing with cryptographic protocols, and this is yet one more example of someone who's learned the hard way. Oops!! _H*